Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

CHAPTER 16
Debugging Habits

If you debug carefully, fully understanding the implications of any changes you make, you can fix bugs and move on with confidence. On the other hand, if you use the debugger to find the specific line of code where an error occurred and implement a quick patch, you are as likely to cause problems as you are to fix them.

To debug as effectively as possible, you should follow certain guidelines. This chapter describes some of the techniques you can use to make debugging safer and more efficient.

Think First

Think before you act. Do not just try things. Study the routine you are debugging so you understand what it is supposed to do before you start experimenting.

Be certain you understand the entire routine, not just the piece of code that contains the bug. The surrounding code may depend on the behavior of the buggy code. If you fix the bug without considering the rest of the code, other parts of the routine may break.

Programmers who read through a routine’s code looking for a bug tend to be more successful than those who just use the debugger to step through the code. If you do not know what to expect, you cannot tell if the debugger is showing you the correct behavior anyway. Study the code first, then act.

Debug When You Are Alert

There is no question that debugging is hard. Understanding what the program is supposed to do, what it actually does, and how you can fix the error takes concentration and creativity. If you debug when you are inattentive, you are unlikely to do an effective job. At best, you will take longer than necessary to find the bug. At worst, you will accidentally introduce new bugs while trying to fix the old ones.

Debug when you are alert. When you are not, perform other chores that require less attention to detail. Fill out paperwork, write progress reports, or just take a break. Return to debugging when you are more alert.

Code Properly While Debugging

All of the coding and testing guidelines described in earlier chapters apply equally to bug fixing. Use proper coding, commenting, and testing practices when you debug.

Code written during debugging is more likely to contain bugs than code written in the program’s initial implementation. Since bugs are more likely while debugging, you should be more careful than ever to code thoughtfully and test thoroughly. Unfortunately, many programmers rush through debugging to get back to more interesting tasks. In particular, they often do not test their changes thoroughly. At best, they test only the particular bug they have fixed and they do not detect new bugs they have introduced. At worst, they do no testing and do not even fix the bug they were originally chasing.

Use correct programming techniques so you can fix bugs once and you will not need to fix them again.

Fix Your Own Bugs

Fix the bugs in your code. You know your code better than anyone else does, so you should be able to fix it most effectively. It will be easier for you to understand the entire body of code that contains the bug, so you will be less likely to make mistakes.

Making programmers fix their own code also puts responsibility where it belongs. If someone causes a lot of bugs, that person will spend a lot of time debugging. Not only does that seem fair, it also keeps bug-prone individuals busy so they cannot contaminate more code. Hopefully, they will eventually adopt better design and coding techniques so they make fewer mistakes.

Fix It Now

Fix bugs as soon as you find them. Do not let the schedule or other pressures make you delay fixing a bug. Bugs are easiest to fix when they are fresh in your mind. Procrastination only gives you more time to forget key details about the code that might help find the bug. Remember, sooner or later you must find and fix every bug. You might as well get it over with right away.

On the other hand, concentrate on one thing at a time. If you are looking for a bug and you find another one, make a quick note about the new bug and continue looking for the first one. Keep working on the original bug until you find and fix it. Then go back and fix the other bug.

Come Back Later

You should fix bugs as soon as you find them partly because you are more likely to remember how the code works. At the same time, if you spend too much time on one bug, your concentration may wane. You need to balance the need to keep the bug at the top of your attention with the need to work when you are most alert and effective.

If you find you are stuck on a bug and are making no progress, take a break and return to the problem later. Give yourself a chance to clear your mind of any preconceptions that may be blocking your progress. Then return with a fresh approach.

Comment Repairs

Do not remove incorrect code. Instead, comment it out and add a note indicating who made the change, when it was made, and why. Later you can use these comments to analyze the project’s bugs. For example, knowing how many bugs the project contained per line of code can help you predict bug counts in future projects. Discovering which code contained the most bugs can help you determine which routines to rewrite later. It may also identify developers who could benefit from additional training.

Leaving the original code in also lets you see it later if there is another problem with this code. You can easily change the code back if it turns out that the original code was correct and some other routine was responsible for the bug. If the bug resurfaces, the comment lets you see what other solutions have been tried so you do not accidentally change the code back to its previous incorrect form.

The following code shows a typical bug fix comment. The keyword BUGFIX makes searching for the bugs easy. This example also includes an incident number used by the project to track bugs.

‘       BUGFIX: 5/27/98 by Rod Stephens. Incident #129.
‘       The following line placed duplicate nodes in the
‘       AVL tree when nodes were deleted.
‘       Set target = replacement
      Set target = replacement.NextNode

See What Changed

While bugs may sometimes seem to spontaneously appear in properly working code, they really do not. Something must change for the code to stop working. If a program that worked before suddenly fails, think about what has changed. Compare a previous version of the code to the new version and see which lines are different. Of course, to make this comparison, you need to keep previous versions of the software. Use a version control system or make frequent backups.

Sometimes when I am about to make a large change that I consider risky, I make a new copy of the code. I then modify that code and leave the original untouched. When something goes wrong, I can compare the new code to the original. In extreme cases, I throw the new code away and start from scratch.